Field of the Invention
The present invention relates to the run-time assurance of programmatic conditions in a computer program and more particularly to a programmatic assertion.
Description of the Related Art
A business rule management system (BRMS) is a software system used to define, deploy, execute, monitor and maintain the variety and complexity of decision logic that is used by operational systems within an organization or enterprise. The decision logic, namely “business rules”, includes policies, requirements, and conditional statements that are used to determine the operational actions that take place in applications and systems. At the minimum, a BRMS includes a repository, allowing decision logic to be externalized from core application code, tools that allow both technical developers and business experts to define and manage decision logic, and a runtime environment in which applications can invoke decision logic managed within the BRMS and execute the decision logic using a business rules engine.
The use of a BRMS has been found to reduce or remove reliance on information technology (IT) departments for changes in live systems. The use of a BRMS also has been found to provide increased control over implemented decision logic for compliance and better business management, and also the ability to express decision logic with increased precision, using a business vocabulary syntax and graphical rule representations such as decision tables, trees, scorecards and flows. Finally, the use of a BRMS has been found to improve efficiency of processes through increased decision automation.
In a BRMS, like traditional middleware, multiple different users can contribute modules of application logic, for instance, to enforce a business policy, automate a process, instantiate a transaction or produce a tangible result. These modules, referred to in the art as “execution units”, are dynamically assembled by middleware software components and executed to form a single enterprise application program. Because of the shared authorship of the execution units, undesirable incompatibilities, redundancy or logical faults can be difficult to detect and eliminate. Such faults include undesirable properties of the input or the output of a particular task, particular guarantees that the dynamically assembled task will possess some specific structure (for instance, that it contains at least one execution unit, or at most a given number), or, a posteriori, guarantee that its execution has followed some desired paths.
In regular programming languages, assertions are one of the common practical mechanisms for achieving defect detection at runtime. Assertions usually are limited to verifying input and output properties in that because program source code is statically defined, assertions on its structure and execution paths would be ineffective and impractical to define and maintain. Analogously, in database management, database triggers are used to implement consistency checks and error corrections. Specifically, when some database management actions are performed on a database, specific execution units—namely the triggers—may be executed to either check the data or take further corrective actions when a transaction displays undesirable properties. However, the presence of multiple triggers on a given database action may in fact raise further issues when trying to check the proper structure of the code that is executed and its execution path.